home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Sep 89 / Y0028-scaleable views-Sep89 < prev    next >
Encoding:
Text File  |  1989-09-08  |  6.1 KB  |  123 lines  |  [TEXT/GEOL]
  1. Item    8522730                         7-Sept-89        19:30
  2.  
  3. From:   D1282                           Power Up,PRT
  4.  
  5. To:     MACDTS                          Mac Developer Tech Support, APL
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    scaleable views
  10.  
  11. Dear Keith,
  12.  
  13. As I trust you recall, from our previous links, I've been attempting to
  14. implement scaleable views via GrafProcs in MacApp.  It's all been going pretty
  15. well, but I have come across a few things that I need to know more about before
  16. I can proceed.  So, batten down the hatches, and prepare to repel MacApp source
  17. questions.
  18.  
  19. Background:
  20. •   TView has been changed to have a fScaleFactor attribute, which can range
  21. from 1 to maxint, with the default setting being 100 (100% of normal).  A view
  22. with a scaling factor of 200 draws at twice normal size (200% of normal), while
  23. a view with a scaling factor of 50 draws at half normal size (50% of normal).
  24. •   A set of GrafProcs do all of the necessary scaling when drawing and
  25. printing.  These GrafProcs are kept in a global variable, gScalingGrafProcs.
  26. •   In TView.Focus(), a check is made to see if the view's fScaleFactor is
  27. 100.  If so, GetWindow.grafProcs := NIL; else, GetWindow.grafProcs :=
  28. @gScalingGrafProcs.  This is not strictly necessary, but there's no reason to
  29. suffer the overhead of the GrafProc calls when they're not needed.
  30. •   The goal of the approach taken is to put all of the scaling code into
  31. MacApp, so that it is transparent to the application program.  Thus, the
  32. application programmer never has to worry about which coördinate space she's
  33. in; she's always in scaled coördinates (what MacExpress calls 'pad
  34. coördinates').
  35. •   Screen scaling has nothing to do with print reduction/enlargement.  That
  36. is, a user could specify a scaling factor such that the contents of the view
  37. fit in the view's window (say, 27%), while having an enlargement of 200%
  38. specified in Page Setup.  These two settings are entirely distinct.
  39. •   I'm using the MacApp 2.0B9 example DrawShapes as my test program.
  40.  
  41. Problem #1:  Focusing in TApplication.TrackMouse()
  42. I'm having problems with TApplication.TrackMouse() and its whole calling chain.
  43. Somewhere in the bowels of these routines, gFocusedView is set to be the
  44. correct view WITHOUT calling Focus on it.  I assume that this is being done for
  45. performance reasons.  The result of this is that when creating new shapes or
  46. selecting existing ones, the rect drawn by TrackFeedback() is not being scaled
  47. properly, because the GrafProcs that do the scaling have not been brought in by
  48. Focus() — because Focus() was never called.  I have kludged my way around this
  49. by leaving the GrafProcs installed all of the time, whatever the scaling
  50. factor.  The kludge works, but I'm not fond of it, and I'd rather see Focus()
  51. called properly.
  52.  
  53. Question #1:
  54. Where is gFocusedView getting diddled, why isn't Focus being called instead,
  55. and how can I call Focus instead of diddling gFocusedView?
  56.  
  57.  
  58. Problem #2:  Move() and MoveTo()
  59. I don't know of any way to intercept calls to Move() and MoveTo() without
  60. patching them (a step I am loath to take).  I need to intercept them, though,
  61. so that the application programmer can pass in scaled coördinates, but still
  62. move to the right place.  My routine would then scale the arguments to global
  63. coördinates, and then call the standard Move() or MoveTo() routine.  This is
  64. the approach I used with the GrafProcs, and it worked quite well, but there's
  65. no bottleneck for Move() or MoveTo().
  66.  
  67. I see a number of possible solutions; I could…
  68. •   patch Move() and MoveTo().  I hate patches.  There has to be a better way.
  69. •   require the application programmer to always map the arguments to Move()
  70. and MoveTo() before calling the routines.  This requires no effort on my part
  71. (now), but it will waste lots of everyone else's time down the road.
  72. •   write two new methods, MoveScaled() and MoveToScaled(), which the
  73. application programmer can use instead of Move() and MoveTo().  The new
  74. routines would accept scaled arguments, do the necessary mapping, and then call
  75. the standard routines.  This requires that every MacApp programmer learn yet
  76. another two methods, and use them correctly.
  77. •   write two new TView methods, Move() and MoveTo(), that get called — like
  78. magic! — instead of the ToolBox routines of the same name.  I tried this, and
  79. although it compiled OK, it died a horrible screaming death when I tried to run
  80. the test program (no surprise there — I'm surprised it compiled!).
  81.  
  82. Question #2:
  83. What should I do?  I have implemented the MoveScaled() and MoveToScaled()
  84. routines, and they do the job (with the caveat noted in the next question), but
  85. I can't shake the thought that I'm missing something — that there's a better
  86. way of intercepting these calls.  Any ideas?
  87.  
  88.  
  89. Problem #3:  Printing Scaled Views
  90. I was pleased to see that scaled views printed properly (that is, at normal
  91. scale, whatever the screen scaling) without my having to give it a second
  92. thought.  However, my fix of the MoveTo() problem came and bit me — it scaled
  93. the given coördinates when printing as well as when drawing to the screen (not
  94. good).  Therefore, if I'm going to continue to use the MoveToScaled() solution
  95. to the MoveTo() problem (as outlined above), I must be able to tell whether or
  96. not I'm printing when MoveToScaled() is called — or I have to get around the
  97. problem some other way.
  98.  
  99. Another way I was thinking of approaching this problem is as follows: since I'm
  100. already changing MacApp, I might as well diddle with its printing code too
  101. (famous last words, I'm sure).  I could modify Print() to save each printed
  102. view's scaling factor before printing, and restore it again afterwards,
  103. meanwhile printing with a scaling factor of 100 (normal).  This would solve all
  104. my problems (though it may create new ones).
  105.  
  106. Question #3:
  107. How can I solve this problem?  How can determine if I'm printing when
  108. MoveToScaled() is called?  Alternatively, do the proposed changes to Print()
  109. seem reasonable, or fraught with peril?
  110.  
  111.  
  112. Thanks for your help!
  113.  
  114.  
  115. James Plamondon
  116. Software Engineer
  117. PowerUp! Software
  118. 2929 Campus Drive, Suite 300
  119. San Mateo, CA  94403
  120. (415) 345-5900 x351
  121. AppleLink: D1282
  122.  
  123.